Protocols such as RADIUS (Remote Authentication Dial In User Service) are commonly used for Authentication, Authorization, and Accounting management. Such protocols can be used to authenticate users or devices, authorize those users or devices for certain services, and account for the usage of those services. For example, to authenticate a user, a RADIUS client will send an Access-Request message to a RADIUS server containing proof of the user's identity (most commonly a username and password) and optionally information about the service to be accessed. The RADIUS server can reply to this Access-Request message with three types of responses: (1) if the RADIUS server deems that the user has not authenticated properly (eg. incorrect username or password) or is unauthorized to access the requested service, the RADIUS server can reply with an Access-Reject message; (2) if the RADIUS server deems the user has authenticated properly and is authorized, the RADIUS server can respond with an Access-Accept message; and (3) if the RADIUS server requires additional information from the user, it can reply with an Access-Challenge message. The last response type, the Access-Challenge message, is most commonly used to request additional information to authenticate the requesting user. Such information can include a password, PIN, token code, or other identifier attesting to the identity of the user. The RADIUS client will retrieve the requested information from the user and then relay it back to the RADIUS server to complete authentication. The challenge-response mechanism provided by the RADIUS Access-Challenge message is commonly used to implement two-factor authentication. In practice, a user attempting to log in to a service (eg. a VPN, website login, etc) will provide his primary credentials (eg. commonly a username and password), the RADIUS client will send those credentials in an Access-Request, the RADIUS server will validate the credentials and send an Access-Challenge back to the RADIUS client, the user will be challenged to enter a secondary factor of authentication (eg. commonly a one-time password (OTP) generated by a hardware or software token) and the response to that challenge will be sent to the RADIUS server for validation. Commonly, the challenge presented to the user in the form of a single instructional message (defined by the Reply-Message attribute in the Access-Challenge message) and an input box to collect the challenge response from the user. Unfortunately, this interface is often statically defined by the service (eg. a single input field with an optional textual caption) and does not provide a rich or interactive mechanism for the user to respond to the challenge. Thus, there is a need in the authentication field to create a new and useful system and method for delivering a challenge response in an authentication protocol. This invention provides such a new and useful system and method.